

This note will be superseded by: a subsequent update- .This system 



Uc are preparing plans for CYBES ISO transaction processing at this 
time. Please review this second revision of CYBER i.SG Transaction 
Processing and return any comments you may have by September 1. 

This document should be viewed as part of a long-range plan, and 
phasing will bs required across several releases. 
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1.1 m£9S£ 


This document describes transaction processing concepts for I 
CYDER ISO. These concepts Mill bo reflected In the AO/R Revision I 
D after review with development and marketing divisions. t 

The' document Is organized Into four sections! • 

11 Introduction* references, and assumptions 
?! Overview of CYBER ISO transaction processing concepts 
/ 3) Features required to support the major concepts 
* 1 ) Summary of major requirements far each NOS/180 component 

1.2 £m,.B£N£££ 


| 


CYBER 180 transaction requirements were Influenced by the 
following source materials! 

1) "Advanced 1/0 and CYBER 80 Forecast Assumptions. 

1980-1990"* F.P.Vince, 12 August 19//. 

2) “Transaction Processing on the CYBER 18* A Competitive 
Analysis"* R.Lanqley, M.Mykkanen, S.Pacholskl. 30 June 
19//. 

1 31 “CYDER 1/0 Transaction Processing, A Competitive 

Analysis", H.J.Mykkanen, 15 March 197/. 

4) "Transaction Strategy", F.P.Vince, 14 March 19//. 

5! “Transaction Processing". R.A. Manning, 24 September 

1976. 

fc> "Transaction Processing Requirements", O.E.Stahl, 4 Harch 
19/6. 

/) “Final Report, Communications Team, Technical Migration 
Strategy Study Team", O.Lleberman, J.Lovgren, O.Owen, 
R,/umlln, 2/ January 19/6. 
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l.C INTRODUCTION 
1.2 REFERENCES 


a» 

“Transact ion 
Oecember 1974. 

Processing 

Strategy", 

L.R.Got tschaIk, 

16 

9) 

"0 IstrIbuted 
Oecember 1977. 

Processlng 

Technical 

Study", K.A.tucke, 

14 


1.3 AS^'MPXi^MS 


CYBER 180 transaction requirements ere based upon the 
following assumptions! 

1> Control Oata*s ability to successfully market large 
genera I-ouroose comouter systems will be significantly 
enhanced In the years to’ come If it maintalrs a 
competitive transaction software system. 

2) Transaction processing products should not be Indenenaant 
or self-contained, but should utilize standard system 
lnterf aces. 

3) CYDER 180 must provide a transaction processing capability 
which addresses the needs of betn systems and services! 
both overseas and stateside. 

4) CYDER 180 should provide a generalized transaction 

processing capability usinq 7AF/N0S as a design b3ss. 

5) . It Is not 3 reoulrement that CYBER 180 be compatible with 

TAF/NOS. Migration support will be limited to the 
preparation of difference documents. 

6) CYDER, 180 should offer In NCS/1B0 R2 a transection 
processing system which Is at least as cacafcle as 
TAF/NOS. 

71 The Massage Control System (MCS! must be supported on 
CYBER 180. 

BJ CYDER 180 systems will frequently Interface competitor 
systems within computer networks. 


l.'f imMUUE:!! I 


Transaction processing, sometimes referred to as I 
telecrocesslng, communications processing, or data base I 
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1.0 INTRODUCTION 
l.l* ENVIRONMENT 


cosmjn 1 cat Ions, Is a mode of computer processing which enables 
multiple users at remote locations to simultaneously access a 
computer system by Inputting structured sets of data. Usually, 
the user Is not a trained computer professional land does not 
want to become one), but a person performing somo work function 
with the help of computers. 

The data input Is processed in a structured way by ore-defined 
program modules. and normally Involves manipulation of one or 
more databases. Frequently. the completion of a terminal 
function (e.g.. evaluating status of an Inventoried part* 
requires several Interactions with the computer system. The 
tormlrat function Is called a "business transaction", and each 
interaction Is called a "system transaction" or simply 
’trer*Dctlom.“ The environment Is time-sensitive, with specific 
constraints placed upon response times lusually In- the range cf 1 
t o 5 seconds) . 

Transaction volumes vary between sites, but rates in a range 
bet'wtso 2 and 10 tr ansae 11 on per second are common. Transactions 
char ,ac t er is t l.cs too vary, but generally each transaction (l.e.« 
system frar.sac11 on) regulres execution of about 20,0 0 0 CYGFR 180 
Instructions, tor application, and 5 logical (12 physical) I/O 
operations, excluding data management logging. The logical 
orocesses of transactions are usually simple and repetitive, and 
the number of types of transactions Is usually small <50-1001 tor 
a elver application. Transactions are usually broken Into 
severe) tasws which are shared among transaction types! each task 
dedicated to a simple specific function. 

Preliminary response time objectives for NOS/180 on a target 
S2 ccn I igurat ion Is 2 seconds average and 957. less than 5 seconds 
for loads of 10 transactions per second. 
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2.0 TRANSACTION PROCESSING OVERVIEW 


2.0 I£iIiS»£Ufl!i_£Sa££SSItl6.-5yLEyj£K 


The following describes some of CYBER ISO’s transaction 
processing concepts from the viewpoint of a user.- 

2.1 £ABH£IIN£_£l5J£Cm£.i 


While recoqnlzlng the need for h1gh-oerformance transaction 
processing, CYBER 180 will emphasize the low to mid oeformanco 
ranee In commercially-oriented applications, A basic transaction 
processing capability will be orovlded in NCS/18Q R2» and o 
competitive transaction processing capability will be provided In 
NCS/180 R3. CYBER 180 will provide the tasking, the oats 

management, and the communication facilities ' necessary to 
efficiently perform transaction processing while processing I 
Interactive and batch jobs. It will be possible to site tuno I 
system performance to benefit selected modes of processing, e.q., I 
It will be possible to define scheduling orioritl-es and' 3 glng 
rates for transaction tasks which 3re unique among those for si' 
tasks. Transaction processes will use standard NCS/1S0 
Interfaces, and will access system resources In the same marner 
as do Interactive and batch orocesses. 

Transaction orocesslng will be supcortel In mu I tl-mainframe 
cont 1 gurat 1 ons, and In multiple hosts within a computer network. 
Loac-levellng will be provided to permit etflciert utilization of 
computer resources. This will not be dynamic I o ad-1 ? ve U n 3 . AM 
transactions from a given terminal are processed or a single 
mainframe. Terminal connection Is made et LOGIN by NkP*s Network I 
Validation Facility (NVF). Several trarssctlon applications may I 
run concurrently. C 3 ch application will be Isolated from another I 
as one job is Isolated from Brother, and may share resources as 
ore Job with another. 
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1.0 TRANSACTION PROCESSING OVERVIEW 
,2 TASKING 

s 2.? JiSUHS 


2.2.1 APPLICATION CONTROL 

| A transaction application will bo a set of tasks, procedures, 

0 flies, and databases utilized for a common purpose or 
X orgar IzatIon. Examples would bo Inventory control, state crime I 

bureau, or TECHNOTEC applications. NCS/180 will ensure that I 

t transaction application names are unique. 

- An appllcaflon will have a single owner. This owner will otso 

own alt resources of the application, and will be accountable for 
311 resources consumed oy tho application. -The owner may 
delegate privileges as he chooses (e.g., via access control I 
entries) to others to administrate the aoollcatlon. Application I 
Aon lr Istrators will be able to develop, test. Initialize, 

terminate,/ recover, and modify applications entirely from remote 

tsrmlrals. Ho host operator intervention will be required. It 
will be possible for the owner to aclegate privileges so that 
ttose responsible for the application’s dally operation 11.e., 

■;i 1 r l 11 s I .lz at Ion, Termination, end . recovery) will not have 

application modification privileges. Programming errors in 
! i application tasks will not cause the application to abort. 

' All access to applications will be controlled fro* remote 

termlrals by Aoolcation Adminlstrators. Login ol selected I 

ter*lrals m.3y be Implicit at application Initialization. It will I 
be possible to grant some termInaIs/users aoollcatlon access on I 
request (e.g., TRANS,APPLl, and to define other terminals as I 
dedicated to an aoollcatlon. A tront-desK terminal In a hotel 
lobby would be an example of a terminal which might be forced to 
a declcated aoollcatlon. 

All terminal LOGIN'S must pass system validation. When access 
to ar aoollcatlon Is granted by tho system. It will be possible 
for the application to further validate access if necessary. For 
irsferce, the aoollcatlon may make further inquiry of -the 
terwlral user, or periodically reissue a reouest for an 
application password. 


2.2.2 TRANSACTION TASKS 


Transactions will be processed by the execution of one or more j 

1ndccerdentIy comotled programs called tasks. Host language call I 
Interfaces will bo provided for COBOL and FORTRAN to make It I 
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2.0 TRANSACTION PROCESSING OVERVIEW 

2.2.2 TRANSACTION TASKS 



possible! to establish a new transaction (NEWTRN), to construct a I 
new task chain 1NEWCHNI, to Insert a list of tasks Into the 
currert task chain (ADDCHN), and to enqueue a transaction tc e 
network queue (SEND). / Transactions will not bo necessarily 
processed on a I Irst-In-fIrst-out basis. It will be possible to 
process transactions on the basis of transaction priority, e.g.. 
certain classes ol transactions may be given priority over otters 
In the same application. 

Associated with each transaction active In an application will I 
be a var1abIe-Ienqth Communleation Block containing a terminal ! 
identifier, a unique transaction identifier, control (lags, date I 
ard time stamps, and an Input message. See Figure 1. This 1 
Common leaf lor. Block will be passed between tasks during execution I 
of i transaction. Passing will be performed efficiently for I 
performance reasons. Blocks will not be moved physically, but t 
Instead will be switched logically bV 'the Transaction Executive I 
as the "move" from task to task. I 



Figure 1 
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2.0 TRANSACT ION PROCESSING OVERVIEW 

2.2.3 TRANSACTION I/O 


2.2.3 TRANSACTION I/O 


Acpllcatlon Tasks may receive two kinds of Inoutt solicited 
and unsolicited. Transaction Tasks wilt be able To perform file 
I/O using standard NOS/180 Interfaces. Including terminal I/O 
using the files INPUT and OUTPUT. A READ from the tile INPUT 
would be an example of a solicited Input. Solicited Inouts are 
routed directly to the requesting task. 

Examples of unsolicited .Input would bet a notification of a 
terminal LOGIN, a notification of terminal timeout, and o 
terminal input to cancel an active transaction. When an 
unsolicited input Is received, a Communication Block will be 
prepared with the appropriate entries, and the Initial-Task 
(ITASKl will be Initiated. Unique terminal identifiers will be 
assigned to NOS/ltIO and NA'l Inputs. If a fatal error occurs 
durlrc execution of a transaction, the cause wilt ba Identified 
in the CommunIcat Ion Block, and the Error-Task (ETASK) will be 
l n l fl a ted. 

Flquro 2 shows a transaction which generates a terminal 
response, and also creates a new transaction which If enqueues to 
a TAX application. j 

unso/i'ti^coil I’n^nt 

f~rr/j sK*l i /vEt/chiw (tsko/, tskoy, tskio ) 

II i 

TSKO I [ AOOCHfJ (TSK03, TSKOS', TSKP7) 




YVATMTR// (CBj rSNOG, •••) 

I 

I 

_i_ 

f rs koZI 


I TSKOZ ■ 


r^KoT] i r- 

prsic/Qj —>** WKiTS (oorF'er) 
Figure 2 


_ i 

TSKO'/ —Y*- i£VP (Tax ) 
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2.0 TRANSACTION processing overview 

2.2.4 TRANSACTION MANAGEMENT 


2.2.4 TRANSACTION MANAGEMENT , ! 

An optional Transaction Management Module will ba provided I 
which will, for a given appllcatlont I 

- verity that transaction types are valid for the terminals I 

sending tne transactlons, I 

- verify that tasks called are valid for the reouestirg S 

terrainsI, ! 

- construct task chains needed to process transactions, I 

- enable and disable selected groups of Terminals and I 

transaction typos. I 

Utilities will be provided which will enable Application I 
Adm Ir Istrators to oreoare and maintain the tables used by the I 
Transaction Manaqem-ent Module, arc thereby manage the 1 
OOP Ilca11on *s functions. I 


2.3 DPT A MANA GEMENT 


2.3.1 DBMS INTERFACE 


DHS-180 wilt provide data management services on CYBER 150. I 
The system will not. however, prevent the use ot foreign data I 
management systems, e.g.. TOTAL. Transaction applications will I 
run as NOS/190 |ohs. and will access OMS-180 uslno stencard job l 
and host language Interfaces. Some features", e.g. recovery, I 
will te available only through 0MS-1AQ and selected AAM I 
structures. I 

If will be possible to share databases between Jobs of all I 
modest batch. Interactive, and transaction. In mui(l-ma Infra me 1 
configurations, databases may be shared between jobs !n alt I 
mainframes. Data security to the record and element levels will I 
be crovldsd by OMS-130. To control concurrent database access, I 
OMS-180 will provide lock capabilities at both tne record-tyca I 
and record levels. Records and record-types which remain locked I 
but rot accessed lor some installation-defined fl-eout period !. 
wilt be automatically unlocked. This timeout,, period *ev he based I 
upon parameters other than fire only: e.g., |oh-!ype, job-state, I 
or number ol records locked. Selected classes may te dually I 
recorded. In the evenl an access to a oually recorded class 1 


COMPANY PRIVATE 


REV 2 
















2 -& 

37/21/78 


2 -T 

07 / 21/78 


2.0 TRANSACTION PROCESSING overview 

2.3.1 cers INTERFACE 


falls. OMS-180 will automatIcnlIy access the second cooy and 
restore the falling cooy. jA class Is an COMS structure which 
defines attributes associated with elemental Items or records^ 

At the comoloflon of each request. OMS-180 wilt return a 
status to the caller. This status will indicate that the request 
was completed successfully, or Indicate why the request failed. 
Per l o c l c a I I y. |ot>s will be required to Issue QUIET-POINT requests 
to CMS-180. These requests will cause OMS-lBO to lock selected 
databases, cooy these databases or recovery-needed data to 
back-up copies, and then unlock these databases. This will not 
effect the operation of other databases. tost database failures 
will oe recovered by OMS-180 without user application 
Intervention or knowledge. For Instance, OMS-180 will be capable 
of regenerating databases using back-up cooies and after-image 
recoros. In the unlikely event that this Is not possible. 
CMS-180 will recover to the last back-up cooy. and will notify 
Job's via returned status that recovery Is necessary. 

/ 

2.3.2 ALL OR NONE 


Nary, transactions will perform more than one database update 
durlrg their execution. For Instance, one m3y update an 
employee's cl ass 1flcal Ion, establish a new salary rate, and wrlto 
ar access Journal log entry. An Important OMS-130 concept Is 
that ol “All or None". Either all updates will be perfo-mod 
correctly, or none will he performed. DM3-180, therefore, will 
provide the BEG I N_P ARCEL» ROLLBACK, and £Ni)_PARCEL reauesfs. 

A DN5-18G Parcel Is delimited by CFGIN_PA RCEt. and EN0_PARCEl. 
reouesfs. database updates to locked records which occur within 
e Parcel will be temporary until an EN0_PARCEL request Is 
processed. inis reauesr will cause OMS-ltO to make permanent all 
updated records currently locked tor a transaction, writs 
after-image records necessary for recovery, and then release all 
locks. Temporary updates will be lost If an ENO_PARCEL request 
Is rot received before unlock occurs. 

The POLLIACK request will cause OMS-180 to undo to the last 
0EGIfi_PA-{CEL all updates to records currently locked for a 
tr ar sac t lor., and then release at! locks. This request may be 
Issuec, for Instance, when a transaction Is to be aborted. 
Updates occurring outside o Parcel or to records r.ot locked will 
be Immediate, and may nut bo cancel led by RDLLJACK requests. 


2.0 TRANSACTION PROCESSING OVERVIEW 

2.3.3 IE ST MORE 


2.3.3 TEST MODE 


I 


i 


it will be possible for Application Adm Ini strators to test 
selected transactions In a "live" environment without endangering 
databases. DMS-180 reouesfs will have a Test Mode par?,meter } 
which may be set by transaction tasks. When this parameter is I 
set, OMS-180 will direct, the reauest to a test database for t 
processing. j 


2.3.<t RECOVERY 


I 


System recovery, and the processing necessary du'-lng norma! I 
operations , to make recovery possible, may effect system I 
performance. Successful recovery wlI i-require the coordination I 
of OMS-180, A A M, and applications. Usually OMS-180 will be able I 
to recover all oermanent updates. and will require minimal I 
operator Intervention. Temporary updates will bo lest durlrg I 
recevery. I 

Ir the event a database Is not fully recoverable, OMS-180 will 1 
restore It to tho Iasi Quiet-Point and place the database In s I 
Recovery State, This will not effect the operation of other I 
databases. Aft OMS-180 requests will have Recovery Mode I 

parameters which may be set by application tasks. Indicating they 
are In Recovery Mode. Only requests witn the Recovery Mode 
parameter set will be processed against databases In a Recovery 
State. This will prevent normal operations with the database 
until It Is (ully recovered. 

At I applications which used this database since the last 
QIJIET-PCINT must rerun their transactions In Recovery Mode and l 
♦ hen notify the Database A dm 1 n Is t r a t or th'at recovery Is I 

complete. Any other Jobs, e.g.* batch Jobs, must also be rerun I 
If they modified the database since the last Cu let-°o Int, ! 
NCS/180 win provide facilities so applications can write message 1 
fogs and rerun transactions and Jobs. Caretu! coordination i 
between applications end Jods sharing databases will oe required I 
to cuarenfea full recovery during rerun. I 

After the Database Adm1nistrator deferolnos that all 
transactions and Jobs necessary tor recovery are complete, the 

database nil! be Placed In 0oeration3l State. This will disable 

Recuvery Mode processing on the database, and wii! begin normal 
datsfcase operations. 
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2.0 TRANSACTION PROCESSING OVERVIEW 
Z.h COMMUNICATIONS 


2*4 iflujiuaiciiufliis 


2.4.1 MESSAGE ROUTING 


A fundamental requirement of any transaction system Is the 
ability to effectively communicate with terminals In a network. t 
NOS/1A 0 will satisfy this requirement with a basic communication I 
facility utilizing standard Interfaces. It will be possible for 
users to replace or augment this facility to meet' Individual 
needs. 

Transactions will be aolo to send messages or transmit tiles 
to a • single destination, or broadcast to -a number of 
destinations. Each destination may be a device, a user, or a 

network queue! anc! may be referenced by logical name. This 

facility will be C0C*s Massage Control System (MCS1 ottering. I 
Hhei? MCS development compromises are necessary, priority wilt bo I 
given to the needs of COCs transaction orocessIng capab 1 111y. t 
The chysical destination, its location In the network, and Its I 

characteristics will be Interpreted by NOS/180 In a manner which 
is transparent to application tasks. Senders may optionally 
3H3lt status Indicating whether all data was properly routed. A 
network queue Is identified byf a queue name, a | ob name, and a 
logical host identifier. 

Selected terminals and users may be Identified as caoable of 
receiving unsolicited output, l.e,, messages unexpected or not 

requested. When messages are sent unsolicited, they will be 
written to message files associated with the terminal or the 
user. If the terminal Is active or the user Is active on a 

terirlral caoable o( receiving unsolicited output, an. alert Is 

sent to the terminal. The terminal operator may then request 
messages to be output to the terminal. 
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2.0 transaction processing overview 

2.4.1 MESSAGE ROUTING 


Console. H 



Solid ieil rwejs.-- _ 

lonsolldiej msj*. -... 


Figure 3 

2.4.2 PAGE BROWSING 


NCS/lf.O will support character, line, and block mode 
communication with display terminals. Outputs which exceed one 
psge (screen) will be queued, and an alert will be giver at the 
terminal Indlcatinq more pages are available. The operator may 
eccess these Pages randomly or sequentially* tlsirg crooer 
application tasks, users will be able to chain Inquiry outputs, 
l.e., save an output from one Inquiry while making another. 
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2,0 TR S ACT ION PROCESSING OVERVIEW 
2.<*.3 FORMATTEO SCREENS 


2.4.3 FORMATTED SCREENS 


Transaction apollcations may optionally. oerform 

or a a t ted-screen I/O to/from display terminals. Such 1/0 wlllt 

reduce the time to generate end modify display Images 

- Isolate screen formats and application program'\-brmats 

- eliminate termlnaI-1ype dependencies 

- mao terminal data to/from application program data 

- perform Input validation and Justification 

Using Format Services, an Application Administrator will be able 
Indore* 3 3 r r°l* consol ° 3 "Picture" of a screen Image* 

Sprlir'J : m P ? tSC ! ed fields and variable formats. Format 
Services nil! transform this Image Into descriptors suitable for 

a P nI;°7 'o-fr-l-scrcen I/°« In this' manner an App I leaf Ion 
Administrator will create new or modify existing screen Images. 

host language Interfaces to FORTRAN and .COBOL wlM use the 
J”" ? t ' PS generated by Format Services when performing 
formatted-screen I/O. An error, e.g., an alphabetic character in 
a ru/rerlc field, durinq a formatTed-screen REAO or RECEIVE v, i f I 
be lnolcated on the user's terminal by a highlighted -"field and 

?rur, U ?'it n c y rs ° r - An error during a format ted-screen WRITE or 
SFNO hill be indicated by returned status tb the caller. 
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2.0 TRANSACTION PROCESSING OVERVIEW 
£;4.3 FORMATTED SCREENS 



Figure 4 


2.4.4 OFF-LINE SPOOLING 


,%ivr:r,:z 

tcrmlral cassette I/O using standard NCS/181 virtual I 

ter mlra I interfaces, e.g., read and WRITE. , 
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2.0 TRANSACTION PROCESSING OVERVIEH 
2.<•. 5 TERMINAL SUPPORT 


2.<1.5 TERMINAL SUPPORT 


W ‘" SUPB ° rt th ' tt.ln„ s 8 „d 

- cnc 751 Terminal Subsystem 
“ GQC 752 Terminal Subsystem 

- CCC 756 Oisolay Terminal 

- I EH .32 7 0 OISDlay Stations , 

The IBM 327,1 oro toco I Is a quasi-standard among many 1 

Olug-roroatlbla Terminal vendors. Thus, NOS/180 wlf^suooort I 
ese o lu3-comBdtlb Ie equipment. Asynchronous block mode, and I 
synchronous mode SOLC, HOLC, and X.25 . transmissions will bo I 
supported. Reference CYBER 180 AO/R Section 12.3.. ' 

The lot I oh inq terminal features will be supported*. I 

* function Keys 
/-tab control 

• highlighted fields ' J 

- protected fields J 

hOS/!30 nefnorK oroducts will provide auto-baud and I 

nutc- term Inal tyoe derectlon, and will support autoWlal up of 1 
terrlrais. idle terminals may be logged out after an 1 

timeout period. This timeout period may be ! 
a furctlon of terminal tybo, line type, and mode of operation. I 

2.A.6 distributed processing 


Application Administrators will be able to submit Jobs to 
initialise applications tnrouqhout a computer network, and to 
transmit object libraries between logical hosts. a y routlrq 
messages to network queues uslnq standard NOS/1 A (Winter fares I 
jhCS), transaction applications will be able to distribute their I 
function and database throughout a computer network. This will | 
be a Level 1 capability as defined in reference m. •' ( 

The actual distribution of processing will be controlled by 
the Net„ 0 r„ Administrator* Transaction tool icat'lons will 
reference network queues uslnq logical Identifiers, and need not 
be concerned with the network corf iqurst ion. The NMwork 
Administrator, using the Network Definition Language, will 
allocate logical nosts to ohyslcal hosts within tne na'-twerk, a rd 
thus c 1 strinute processing. 
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2.0 TRANSACTION PROCESSING OVERVIEW 
£;^;t_0ISTRIBUTE0 PROCESSING 



Figure 5 


? - 5 iPEU£AIIli!L.Si!P£fl21_SCETHA&£ . , 

HIM provide a number of software packages which will | 

oackacec u ' ° l '' ars ln s crt,r -‘* ISO transaction environment. These I 

packages wilt be rtevelooed by Implementing a ' transaction 
application for a CYBER 1 A 0 rw, transaction ! 

i n fo- ra , r,n a , 1 u customer* This customer way bej j 

in f err a I to CDu (e.g., CONSOURCE), or it may be external. I 

are S °!dentl'f! 0 w th * fol! ° w1 ^ 'actions will be provlced. These I 
Sections s'and k« 3S “ (SI responsibility In I 

i 

** LHASXJL,,_ An application task called bv the 1 

«ch 5 ?rU»rty <eCUf ‘re ,,S ^ ‘S.Cutid for I 

each t. ansactlon. Interprets ursollclted messages and ! 
routes to appropriate tasks for processing. j 
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2.0 TRANSACTION PROCESSING OVERVIEW 
2.S APPLICATION SUPPORT SOFTWARE 


? > ECCQC_LaslI_l£I4SKia_ An apDlIcstlon task cabled by tha 

Transaction Executive when a transaction fatally aborts. 
Performs aporoorl3te orocasslng, e.q., ROLLBACK' of uodates 
and notifying the terminal user or . flootication 
AOministr ator. 

3) jAjiOlQiSlealflr_laXfirlasia*^. Provides visibility and control 

of an abb Iica11 on* An Application Administrator may. for 
Instance, suspend selected transactlqn types, initiate 
lest Mode processing, or see the resources currently owned 
by an aopIication. 

*>) Ir-iiDSacllan_S<lCUQi_ Resubmits transactions and; batch jobs 

for rerun after database fallback to a Quiet-Point, 

5> EflS2UCCfi-_Eeu.QCl.Si_ Prepares reports showing the*’ resources 
used by an aoultcatlon. Options permit r'eports by 
application. By transaction, by terminal, and by user. 

/ 

61 Cassfillfi-Subnilij.. Reads transaction massages from taoe 
cassettes, and submits these as transactions for 

execution. ; • 

7 > fie3S.33fi_Eursi.na. l _ Parses messages for. use by application 
tasks. Edits free field terminal Inputs into'-forms more 
suitable for task processing. 
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3.0 TRANSACTION PROCESSING REQUIREMENTS 


3.0 J£AE5fi£IIQ!i_ESaCES£IN£_gEQSilJS£MEViI5 


The following describe 20 transaction processing conceots, sod 
the NOS/180 features required to support each, Oesoonslb1t1ties 
are cesignated as follows* 


NCS/18C 

10) 

= 

CYBER 180 Operating System 

OMS-180 

(0) 


Data Management 

Ne t. Prod. 

(N) 

= 

Network: Products 

Comp,Prod. 

(C) 

= 

Compiler Products 

Tran.Exec. 

IE) 

= 

Transaction Executive 

Spec.Prog. 

(S) 

= 

Special Programming 

User-Aool. 

CU> 


User Application 


^ XCfiDSUClJ.QD_PcJ*QCJLli.iSiL_ It will be possible to process 
transactions on tne basis of transaction priority within 
an application. It wil! be possible to alter a 
transact 1 on’s priority during its execution. This mearst 

NOS/180 -- must orovlde a proqram management command 

to change the priority of a task, 

-- most enable a called task to inherit the 
priority o( a caller task, 

Como.Prod. -- must provide a language call interface for 
COBOL and FORTRAN to cnange a task's 
priority. 

USE-L2Jdri.fiv£liD2A_ It will be possible to achieve 

I oad-IeveI 1 no In a multi-mainframe conf1qura11on by 
sharing an aooI 1cafIon*s transaction load between 
mainframes. This will qqX be dynamic Ioad-1 eve ling. All 
transactions from a given terminal are processed on a 
single mainframe. Terminal connection Is made at LOGIN by 
I,HP'S Network Validation Facility INVFI, Ihis maarst 

NOS/180 -- must permit a transaction aoollcaflon to 

execute concurrently in more then one 
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mainframe In a mut tl-mal-nframe 
con 11guratIon. 

-- must suoport concurrent access to shared 
files from all mainframes In a muttl- 
malnframe configuration. 

OMS-180 -- must support concurrent access and update of I 

shared databases from all mainframes In a I 

' multi-mainframe configuration. , I 

Net.Prod. -- must permit Implicit login.-'.of selected I 

terminals at application initialization. I 

Jr 

-- must be able to select the malnf'rane for 
terminal connection at LOGIN on the basis 
of! NOL definition, hardware status, 
application status, or-host ooer.'ator 
direction, ‘ aj, I 

-- must reroute terminal connections In the 1 

event of mainframe or link failure (need not I 
be transparent to the terminal jyser). I 

3) Si naia Ow ner. Each transaction aoolicatlon I I have a 
single owner. This owner will also own a 11 .resources of 
the aoolicatlon, and will be accountable for.SlI resources 
consumed by the application. This meanst ’*■ 

NOS/180 -- must run each application as a Job, 

-- must support multiple network terminals 

per | ob. 

-- must permit lobs to perform Job. library list 
maintenance during on-line operation, 

-- must permit users to request the resources I 
consumed on a transaction basis. I 

• i* 

-- must permit users to submit |ot> 4 » to I 

logical hosts In a computer refHork. 

4) Task Chains. It will be possible for one task to initiate 
another task or task chain, with the option of continuing 
execution or awaiting completion of the ca'lied task or 
task chain. This means! 

Tran.Exec. -- must maintain a task llsf for each active 
transaction, 


— must orocess NEWTON, NEHCHN. AOOCHN, and 
ENDTSK requests. 


-- must initiate the next task In the task 
list when the previous task completes 
(ENDTSK), or If none, terminate the 
transaction, I 

-- must release all locks at the termination of 1 

a transaction. I 

Comp.Prod. — must provide COBOL and FORTRAN language call I 
interfaces for NEWTRN, NEWCHN, AOOCHN. and 
ENDTSK requests. 


5) £HMUQigillia£L-Mgc!lx_ ‘A var lah f e-I ength data block will be 
passed from one task to another during execution of a I 
transaction. This block may be saved between I 
transact Ions. This means! ! 

Tran.Exec. -- must fetch and prepare a communication 
block for each unsolicited input, 

-- must pass the communication block between 
transaction tasks or ENOTSK, 

-- must maintain communlea11 on block storage 
space tor each active terminal, 

-- must optionally save the communication block 
at the completion of a transaction. 

-- must save communication blocks when 
recoverlng. 

Comp.Prod. -- must rt3ka communication blocks visible to i 
C030L and FORTRAN users. I 


f> .te5JLLici.t25LInaillji._ When an unsolicited input is recelvod, 
a communication, block will be prepared with ths 
appropriate entries, and the task ITASK will be 
Initiated. Applications will be capable of accepting 
unsolicited Input wnile a transaction Is In progress. 
Thi.s means! 

NOS/1PO -■ must route solicited Inputs to requesting 
tasks. and unsolicited Inputs to tie 
transaction executive. 
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Net.Prod. -- must permit Input from termLYfits while 


transactions are active for the same . 
terminals. 

Tran.Exec. -- must fetch and prepare a communication block 
for each unsolicited Input. 

-- must establish an Initial task list and then 
Initiate ITASK, 

« 

-- must Indicate cause and Initiate the task I 
ETASK when a fatal error occurs during 1 
execution of a transaction, 1 

must bo able to terminate all -transactions I 
for a given terminal" tether than the 1 

caller), and then Issue the necessary ! 
OHS-tAO ROLLBACK reauests. I 

t Comp.Prod. -- must orovlde COBOL and FORTRAN Ianguage ca I I I 
interfaces for reauests to terminate all I 
transactions active for a given terminal. I 

/) transac t 1 on _Management. An ootlonal ‘-Transaction I 

Management Module and associated utilities-/, will be I 

provided which enable Aoollcatlon Administrators to manage 1 
an aopIIcatlon"s (unctions. This moans! • I 

Tran.Exec. -- must provide utilities to prepare and I 
maintain module tables. 1 

-- must verify, using module tables, that I 
transaction types are valid-'' for the I 

terminals sending the messages, . 1 

•- must construct task chains needed to process I 
transactions, ... I 

-- must process requests to enable and disable I 
selected groups of terminals and•transact 1 on I 
types. I 

85 Ye rml pal S tatu s. It will be possible for a terminal user I 
to status the system at any time. A terminal user may 
receive the Input and output messages associated with the 
last successfully completed transaction for the terminal.. 
This means! - 

NOS/L80 -- must route unsolicited Input's to the 
transaction executive. 
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Net.Prod. -- must permit Input from .terminals while 
transactions arc active for the same 
terminals. 

Tran.Exec. -- must fetch and prepare a conmunlcatlon 
block for each unsolicited Input, 

-- must establish an Initial task list and then 
Initiate ITASK. 

User-Apol. -- must maintain terminal activity records, 

-- must prepare and send status response to the 
terminal! last messages are available from 
the communication block. 

9) NAM Mes sages. It will be possible to Initiate execution 1 
of a task as a result of a terminal being newly connected, 
reconnected durlnq recovery, disconnected, or logged out 
from an application. This means* 

N0S/18Q -- must route unsolicited Inputs. to the 

transaction executive. 

Net.Prod. -- must prepare and send an unsolicited message 
to an application on terminal connect, 
reconnect during recovery, disconnect, or 
logout. 

.Tran.Exec. -- must fetch and prepare a common 1 cat 1 on 
block tor each unsolicited Input, 

-- must establish an Initial task list and then 
initiate ITASK. 

10) Standard Int erf aces. Transaction applications »UI use I 
standard NOS/lhO Interfaces, and will have the same access 
to system resources (e.g., tapes, files, databases, and 
network products) as do other applications. This means! 

NOS/ISO -- must process transaction requests using the 
seme Interfaces as requests from other 

modes. 

DMS-180 -- must process transaction requests using the 1 

same Interfaces as requests from other 

modes. 

Met.Prod. -- must process transaction requests using the 
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sane Interfaces as reauests froN other 
modes. 

Como.Prod. -- must provide common Interfaces to’atl modes' 
of processing. v-. 

Tran,Exec. -- must require no special transaction-only 
services from NOS/180 or. Its product set. 

v 

11) L,PCK_C2Dlcai*_ DNS-180 nil) provide loch caoabilltles at I 
both the record-tyce and record levels. Record-typcs and I 
records which remain loched but not accessod .for some I 

Installation-defined timeout period will be unlocked. I 

This meanst ’• I 

timer for I 

v, 

and unlock I 

-- must enable transactions to be the “owner" I 
of Iocks, 1 

-- must monitor inactive . locked aheas, and 
unlock these after a timeout period. 

Comp.Prod. -- must provide COBOL and FCRTRAN' .language 

Interfaces to lock and. unlock record-types I 
and records of DMS-180 databases. I 

Tran.Exec. -- must release all locks at the termination of I 
a transaction. . t 

1?) Quiet-Poin t. 0MS-18Q will process QUIET_POINT requests. I 
host database (allures will be recovered by QMS-180 I 
without user application Intervention or knowledge. This I 

ceansi • 1 

0NS-18Q -- must copy selected databases or I 

recovery-needed data . to back-up copies I 

during Quiet-Point processing, I 

-- must lock databases during Gtilet-Polnt 
operations, ■■ 

-- must oe able to recover databases, or I 
portions o( databases, concurrently with t 

other system operations, . 1 


NOS/180 -- must provide a clock or interval 

QMS-130 use. 

DNS-180 must process requests to lock 

i record-types and records. 
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-- must provide tha necessary Database 
Administrator Interlace necessary to manage 
database back-up and recovery. 

-- must provide COBOL and FORTRAN language call I 

Interfaces for QUIET„POINT requests. I 

Tran.Exec. -- must Idle and restart Its application when I 
requested by a task Ino-op It already idled I 
or restarted!, • 

User-Appl, -- must periodically request OMS-180 to 1 
Quiet-Point, I 

-- must request the apollca*Ior to Idle before t 
Issuing 0UIET_P0INT requests, I 

-- must periodically request Quiet-Point status ! 

from OHS-iAQ, I 

-- must request the application to restart I 
after completion of Qulot-Polnt processing. ! 

13) RO LL BAC K / ENO PA RCEL. OMS-1SO will process 9EGIN_P.AR.CEU I 
ROLLBACK, and ENO_PARCEL requests, and will ensure that I 
“alt or none" of each parcel of updates are performed. I 
This ir.eanst • 

DMS-180 -- must treat all updates to locked * 

record-types and records which occur within I 

Parcels as temporary until an cN 0„PARCEL I 
request Is received, I 

-- must make permanent "all or mono" of the I 

temporary updates for a transaction and I 

release locks when an ENQ_PARCEL request Is l 

received, I 

must write atter-lmage records for the 

Durooses of recovering from the last 
Quiet-Pqlnt, 

-- must undo all temporary updates for a I 
transaction and release locks when a ! 
ROLLBACK request Is received, i 

-- must undo all temporary updates to I 

record-types and records when unlocked, with I 
an unlock option to make updates permanent, I 
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-- must provide COBOL «nd FORTRAN language cal! » 
Interfaces to OMS-180 8£GIN_PARCEL, I 
ROLLBACK, and ENO^PARCEL requests. I 

User-Aool. — must Issue OMS-180 BEGIN_PARCEL, 'ROLLBACK. I 
and £N0_PARC£L requests. I 


18* Xfisl—It nil! be possible' for Application I 
Administrators to test selected transactions in a "line" 
environment Without endangering databases. This means'* 

QHS-ieQ -- must evaluate the Test Mode parameter on I 
QMS-180 requests. I 

-- must support test databases, ‘ j 

** must provide COBOL and FORTRAN language call I 
Interfaces for ONS-180 requests which 1 

include Test Mode Parameters. I 

/ User-Aopf. —- must provide any logic necessary to select 
which transactions are to run In Test Mode, 

-- must set the Test Mode parameter on ONS-180 I 

requests, _ ( 

-- must reroute I/O on the basis of lest Mode, 
if desired (network products will not 
evaluate Test Mode parameters). 

15) CJiia!lASA__£fl&CSLfiCltx_In the event a database Is not fully I 
recoverable. It will be possible to rerun applications and I 
Jobs concurrently with other system operations. This I 

means* t 

OMS-180 must always be able to restore a database to t 

the last Qulet-Polnt, 

-- must process requests to restore a database 
to the lost Qulet-Poinf, 

-- must process for databases In Recovery State 
only requests Kith the Recovery Mode 
oaraiTiQt«rsetf 

-- must return databases to Operational State -I 
when directed by the Database A dr In I strator, | 

““ must process for databases In Operational 
State no requests with the Recovery Mode 
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parameter set** 

-- must provide the Oatabase Admlnlsfrater 

Interface necessary to control the recovery 
process, 

-- must provide COBOL and Fortran language call 
Interfaces for OMS-180 requests which 
Include Recovery Mode parameters, 

-- must provide COBOL and FORTRAN language cal! 
Interlaces for requests to restore databases 
to the last Quiet-Point. 

-- must orovide recovery of AAM files 1 o the 
last Quiet-Point. 

Spec.Prog. -- must resubmit 'transactions (via NEWTRN or i 
SEND requests) with Recovery Mode parameters 
set on OMS-180 requests. 

-- must signal tn« Oatabase Administrator when 
recovery Is complete for a job or 

application, 

-- must periodically request the recovery 
status from DMS-183, 

-- must request the application to restart 
after operational status Is returned by 
QHS-130. 

User-Appl. -- must log transactions and jobs so they may 
be resubmitted for recovery, 

-- must request the aopllcatlon to Idle when 
recovery status Is returned from DMS-130, 

-- must Initiate aopllcatlon and job rerun 
procedur es, . . 

-- must reroute I/O on the basis of Recovery 
mode, if desired (network products will not 
evaluate Recovery Mode parameters). 

JlSiH.id.q—£ayllng t _ Tasks will be aole to send messages and I 
transmit files to a single destination, or broadcast to a I 
number of destInations• Eacn destination may no a device, 
a user, or a network queue! ana may be referenced by 
logical name, mis facility will be COC’s Messago Control 
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System (MCS) offering. This means* 

NOS/180 -- must orovlde message queues which may be 

associated with selected tasks, 

-- must provide an SCI statement to send 
messages or transmit flies to single devices 
or users. 

Net.Prod, -a must transmit messages and files to network 
queues. users. and devices located 
throughout a Computer network, 

-- must transform logical device and queue 
Identifiers to physical devices and quaues. 

must accepl Both single' destination and 
broadcast requests. 

must Identify those users and devices 
capable of receiving unso I lc lted' out put, 

-- must maintain an unsolicited message quoue 
for each user and . device capable of 
receiving unsolicited output. 

must enqueue unsolicited messages for users 
and devices, and send alerts If currently 
active, 

-- must send an alert at terminal login time It 
unsolicited messages await the user or 
device, 

-- must transmit unsolicited message queues to 
terminals on request, : 

-- must discard unsolicited messages after an 
Installation-defined timeout Period. 

Como.Prod. -- must provide COBOL and' -FORTRAN language 
Interfaces to send and broadcast messages 
and files. 



User-Apol. -- must send broadcast messages, and 
messajes to network queues. 


1?) tags_Brow sing . Display terminal output's which exceed one 

page (screen) will be queued, ard an alert will be given 
at the terminal Indicating more pages are available. The 
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operator may access these pages randomly or sequentially. 
This meanst 

Net.Prod. -- must be able to enaueue pages for display 
terminals. 

-- must alert terminals when multiple page 
(screen) outputs 3re sent, 

-- must permit users to select poges for 
dlsolayt next, back, first, last, forward 3, 
back 6, etc., 

-- must optionally display the current page 
number with each page, 

• ' -- must idantify page-end by either line count 

or delimiter, 

18) Formatted I/ O. Application Administrators will, be able to I 
create new or modify existing screen image definitions 
from remote consoles using Format Services. These Imaqe 
definitions will be used during for«af1ed-screen I/O. 
This means* 

Net.Prod. -- must support highlighted fields and curso-’ 
control on display terminals. 

Comp.Prod. -- must orovlde COBOL and FORTRAN language cal! I 
Interfaces necessary to perform I 

formatted-screen I/C, 

-- must map terminal cata to/froa application 
programs, 

-- must provide a Format Services utility which 
will transform remote console "pictures*' 
Into Image definitions, 

-- must maintain Image definitions for use 
during formaffed-screen I/O, 

-- must type validate 3nt right/left Justify 
I/O data, 

-- must send to the console indications of 
Input errors. 

19) fil.LsS.ln>L_S£l2QiiQ2i_ Terminal operators will be sble to I 
perform d1 so I ay-to-1aoe cassette operations in an off-line 


COMPANY PRIVATE 


REV Z 






3.0 transaction processing requirements 


3-12 

07 / 21/78 


Uocal) mode, and later transmit the cassette massages to 
a host comouter. This means! 

NOS/180 must suooort tape cassette I/O using 

standard I/O Interfaces. ' 

Net.Prod. -- must support terminals with off-line flocsl) 
node of operation, 

"* nust Identify tape cassettes as network 
devices, 

-- must support tape cassette I/O using 

standard network I/O procedures. 

Coop.Prod. -- must provide COBOL and FORTRAN language 

RECEm 0 * 5 t0 D0P,0rm I/0 ’ READ' and 

Spec.Prog. -- must oerform tape cassette Ul/C using I 
/ standard NOS/lflO Interfaces, I 

must submit transactions for execution. I 

(Jser-Appl, -- must initiate tha Cassette Subml t'u 1111 ty, | 

2fl ’ IfirjiiEUl_SU2IEfln±x_ NOSV180 network products will 
the following terminals and their functions! 

- COC 751 Terminal Subsystem 

■. * COC 752 Terminal Subsystem , 

* COC 756 Olsplay Terminal 

- IBM 3270 Display Stations 

This iteaesl 

Net.“rod. -- must provide auto-baud detection end 
aut o-1 e'-mlna I type detection, 

-- must suoport auto-dlal up of terelnats, 

-- must permit logout of terminals Idle for an f 
Installation-defined timeout period, I 

-- must support • BSC and . SDLC communication 
oro t ocoIs , 

* DI'i.t.ci£luleil_Prec.2.£S.iMx_ Transaction app Heat l oris will be I 
able to distribute their functlor and database throughout 
a computer network by routing messages to network queues. 
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In ter f aces°?MCS? • *{h] shears, ,0r ** d USl " 9 HOS/1SO j 

NOS/180 -- must provide message queues which may be 

associated with selected tasks, 

-- must permit fobs to oerform Job I Ifcrary list 
maintenance during on-line operation, 

-- must oermlt users to submit Jobs to logical 
nosts in a computer network# 

Net.Prod. — must be able to transmit files «* 
Transparent text between hosts In a computer 
ne♦work, 

*- must tranSmlt messages and files to network 
queues located throughout a computer 
network, 

must transform logical queue identifiers to 
Physical Queues* 

Comp,Prod. — must pmvlde MCS and ■ the associated I 
interfaces to COBOL and FORTRAN. I 

Tran.Exec. — must Initialize application files and 
queues, and then schedule ITASK. 

User-AppI. -- must orovide the |obs which Initialize an 
. application,- Its object libraries end files. 

In eacn logical host In a computer network. 

22> ACfiiiialijm—Si!222Ci—S2liwa££x_ COC will provide a number I 

cIbIr l«n r t DaCk9 ?? S HMCh WlM 3sslst customers Ir 8 | 

CY r.R 180 transaction processing environment. This mesnsi I 

NOS/180 — must permit t asks to request resources I 

consumed on a transaction basis. I 

Spec.Prog. -- must provide a basic Initial task (ITASYS, I 

must provide a basic error processing task I 
ItiASK >, l 

must orovide a transaction application I 
Interface To the application Adm 1 nistrator, I 

* ust provide a utility which will resubmit I 
transactions for rerun after fallback to a I 
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Quiet-Point. 

V "ost provide a utility which reports the 
resources used? by application, transaction, 
terminal, and user. 

-- must provide a utility which submits 
transactions stored on tape cassettes, 

-•* ">u5f provide a utility which parse's messages 
for use by application tasks. 
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Summary 


Requirement 


I Peso. 1 
■a ---- - * 
I I 

»0 I 
I 1 

10-C I 
I I 

I I 

! 0 I 

i ; 

10-0 ! 
IN I 


Transaction Priorities 


MHF Load-Levellng 


Single Owner 


Task Chains 


Communication Rlock 


Unsolicited Input 


Transaction Management 


Tasks inherit caller's 
priority 

Request to change task's 
prlor 1 f y 


SSamo application In auttl- !0 
I mainframes 1 

IConcnrrert access in MMF 10- 

IImplicit terminal login IN 

ISelectablo mainframe cornecfIN 
I in MMF [ 

IReroute terminal connectIansIH 
I I 

I Ado I leat Ions run as Jobs !0 
IMultipte terminals per Job 10 
I On-line library maintenance TO 
tPequest transaction rescurcesO 
ISubmlt to logical hosts SO 

1 I 

Itgsk list per transaction IE 
IProcess task list requests !E- 
I Initia t e nex t t ask IE 

IReloase locks at termtnatIon IE 
i of transaction I 

! 

Prepare communication blockslE 
Pass communication blocks IE 
Maintain Ct? storaue areas IE 

S3V» ca at transaction end IE 

Save CO's when racoverlrq IE 

Commun, block visibility 1C 

I 

Route input messages 10 

Permit busy terminal input IN 

Prepare communication blockslE 
Establish initial task list IE 

Initiate £TAS< on errors IE 

Ter mlna f e ac 11 vo IF-; 

transactions ! 

I 

Module tables utilities IE 

Validate transaction typos IE 
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» 

tConstruct tasH chains 

IE 1 

1 



tEnabfe and disable groups 

IE 1 

■ 1 

t 8 

ITermlnal Status 

i 

IRouta Incut messages 

■1 t 

.10 1 

1 


1 

IPermlt busy terminal Innut 

1N 1 




IPreoare communication blockslE ! 



J 

1 Establish Initial task list 

IE 1 



1 

IHalntaln terminal busy 

IU 1 

1 


1 

1 status 

1 I 

1 



IPrepore and send status 

IU 1 



1 

1 

I resoonse 

t 

1 1 


I 9 

INAM Messages 

1 

IRouta innut messages. 

1 1 
10 1 

1 


# 

• 

(Send messages re terminal .' 

IN 1 



1 

I connection : 

1 1 



1 

IP.ranare communication blockslE . 1 



1 

t 

(Establish Initial task list 
| 

IE 1 


110 

1 Standard Inter tacos 

1 

ISamo processing tor 

1 1 
10-0-NI 

1 


1 r 

1 all modes 

1 1 



1 

(Common Interfaces for all 

IO-C 1 

1 



1 modes 

! 1 



1 

1 No transaction-only 

IE 1 



1 

1 requirements 

1 I 



1 

t 

IRecord level security 

10 1 

1 

t n 

Hock Control 

1 

IProylde clock or interval 

1 1 

to 1 

1 



1 t1mer 

1 1 




1 l.ock/Un 1 ock racord-tyoas 

10 1 

1 


1 

1 andrecords 

t 1 

1 



ITransactlon locks ownership 

10 1 

1 

g 

1 

lllnlock after timeout perlodltO 1 

1 



IReloase locks at termlnatlonlE 1 

1 


j 

I o( transaction 

! I 

1 

112 

1Oulet-PoInt 

ICopy to back-up cooles 

I 1 

ID 1 

1 


1 

Hock databases during 

10 1 



1 

1 Quiet-Point ■ 

1 1 



t 

1Concurrant database recovery!0 1 

1 


1 

(Database Administrator 

10 1 



1 

I Inter face 

1 1 



1 

(Periodically request Quiet-- 

IO-U 1 

1 


1 

1 Point 

1 I 

1 


1 

lldle application before 

10-E-UI 

1 


1 

I Qule f- p oIn t 

1 1 

1 



(Periodically status 

IO-U 1 

1 


I 

1 •Quiet-Point 

1 1 

1 


1 

IRestart application after « 

10-E-UI 

1 


1 

1 Quiet-°olnt i 

1 

I I 

t 1 

1 
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3.0 TRANSACTION PROCESSING REQUIREMENTS 



1 13 

IR0LLBACK/ENO_PARCEL 

ITr^at locked updates as 

!□ t 

1 



l tcnoonary 

! 1 




lUodate "all or none** on 

10 1 




1 £NQ_PAqCEL 

1 t 

1 



IWrite after-images Tor 

10 I 




J recovery 

I I 




tUndo temporary updates or 

to 1 




I ROLLBACK 

I 1 

1 



tUndo temporary updates on 

10 t 




1 Un1ocH 

I 1 




1 Request 8EGIfl„PARCEL» 

IO-U 1 

1 



1 ROLLBACK* cmd lNO_PARCEL. 

• 

1 1 

! 

514 

ITest Mode 

i 

l£va)uafo Test Hode 

1 1 

10 ! 

1 



1 parameters 

1 ! 

1 



ISupocrt test databases 

!0 I 

I 



ITrahsactlon selection logic 

IU 1 




tSet Test Mode parameters 

IU 1 




IReroute Test Mode T/0 

t 

!U 1 


1 IS 

ICatsbase Recovery 

i 

t Las t Quiet-Point restorable 

1 ! 

10 1 

1 



IPequests to restore databasssQ 1 

1 Recovery State/Modo roquestslO 1 

I 

1 



IOooratIona 1 State after 

10 V ! 




1 recovery 

1 1 




1Qporationa1 Stata/Mod* 

ID 1 

t 



1 requests 

1 1 




lOatabase Administrator 

10 1 




1 int ar f ace 

t I 




iLog Transactions and Jots 

IU 1 

1 



! for recovery 

t 1 




lldle application for recoweryC-E-U! 

! 



1 Initiate rerun process 

IU 1 

1 



IResubmit transactions in 

IS 1 

1 



1 Recovery M ode 

1 1 

1 



l°eroute Recovery Mode I/O 

IU 1 

1 



! Signal OB Admin. after 

IS 1 

I 



l recovery 

1 1 

1 



1 Periodica 11 y status 

10-S I 

1 



1 recovery 

! S 

1 



IRestart application 

IC-E-SI 

1 



t after recovery 

! I 

I 



IAAM files recovery 

1 

10 I 

! 

116 

Ikessags Routing 

lAssociate queues with tas^s 

! I 

1 0 1 

1 



ISCL statement to send 

i o : 




ITransmlt messages and files 

i n : 




{Transform logical tc 

1 N 1 




' ohvsleal dev ices 

i ! 




1 Accept single and 

IN-C 1 
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0 TRANSACTION PROCESSING 

REQUIREMENTS 



9 

i 

1 broadcast requests 

1 

1 

J 


tldentlfy unsolicited 

IN 

1 

t 

t 

1 destinations 

t 

1 

t 


(Maintain unsolicited 

IN 

1 


! 

3 message queues 

1 

1 

1 

t 

lAlert on unsolicited 

1 N 

1 

8 

! 

1 output 

. i 

1 

I 

t 

lAlert at terminal login 

IN ‘ 

1 

3 

I 

ISend unsolicited messages 

IN 

1 

f 

I i 

1 to output 

t 

1 



IDlscard messaqes after 

T N 

1 

1 

J 

1 timeout 

1 

1 

I 

t 

ISend broadcast and queue 

. IC-U 

1 

t 


1 messages 

1 

1 

117 

JPag® Drowsing 

lEnqueue multiple pages 

1 

IN 

I 

1 

t 

{ 

1 output 

i 

1 

I 

t 

lAlert when multiple pages 

IN 

1 



IProcess cage selection 

IN 

1 


3 

1 requests 

1 

1 

1 

3 / 

lOlsolay page number 

IN 

1 

t 

J 

1 optlonal ly 

1 

1 

| 

1 

t 

ILlne count 1 page delimiter 

IN 

1 

1 18 

IFormatfed I/O 

1 High 1Ighted fields and 

‘ 1 

!N 

1 

1 

> 


I cursor control 

i 

1 

I 


(interfaces for formatted- 

IC 

1 

1 

t 

1 screen I/O 

1 

1 

1 

1 

1 Map for matted-screen data ' 

IC 

1 

I 

1 

IProvlde Format Services 

IC 

1 

1 


1 utility 

1 

1 

1 


Maintain Image definitions 

IC 

1 

3 

* 

(Validate and Justify 

.IC 

1 

3 

3 

1 f orma t ted data 

1 

1 

i 

3 

ISend error Indications to 

1C 

1 

1 

i 

t 

t conso 1 es 

1 

1 

119 

ICff-Une Spooling 

1 Initiate utility 

•1 

IU 

1 

1 


1 

(Cassette I/O ula standard 

10-C- 

SI 

I 

1 

1 Interfaces 

1 

1 

3 

t 

ISubmlt transactions 

IS 

1 

1 

t 

l!.ocdl-mode terminal support 

IN 

1 

1 

l 

ITape cassette 1 dan11 fleaf lor 1 N 

1 

1 

t 

ICassette I/O via standard 

IN 

1 

1 

| 

1 

1 protocols 

1 

1 

120 

ITermlnal Suooort 

lAuto-baud and auto-type 

t 

IN 

1 

1 

1 

1 

lAuto-dlal up support 

1 N 

I 

I 


IIdie terminal logout 

1 N 

I 

3 

t 

I8SC and SOLC protocols 

1 N 

1 
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» 

1 21 

(Distributed 

Processing 

! 

lAssociatc queues with tasNs 

1 

10 





I0n-llne library maintenance 

10 





ISubmlt Jobs to logical hostslO 





lRoute files between 

! 0 





1 logical hosts 

I 





(Transmit files between host 

5 1 N 





Ifransmlt messages 1 tiles 

1 N 





(Transform logical to 

1 N 





1 Physical devices 

1 





IMCS and interfaces 

IC 





■Initialize application flleslE 





IProvlde Jobs to Initiate 

IU 


I 



1 a op 1ic a tions 

t 


122 

1Appllcatlon 

Support 

IMaslc In It 1 a l-TasN UTASK) 

t 

I s 





ISasTc Error-Tash (ETASKf 

1 s 





1 Administrator Interlace 

1 s 





1 fransact lors rerun utility 

1 s 





(Resource report generator 

10-S 





(Cassette submit utility 

IS 


1 

♦ — - 



(Massage parsing utility 

IS 

1 
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h.O kOS/180 COMPONENT REQUIREMENT 


** * 0 H&&/JlM--CflrtP ONENT R EOUf RF HEtll 


t>e ' 0t ' are th * necessary ti support 

tra.nsac Hen processing. The YES/NO codes indicate whether 

documents?** d9TIned ln eurp *" t CYBER WO design or 6b)ectl», 


lOefIredt 
fCaoab. I 


Requirement 


OMS-180 


l ITasks Inherit caller’s orlorltY 
’ I Request to chbrige task's priority . 

1 ISame application ln multl-maln frames 
; IConcurrent tile access In MMF 

> I Aoo I icatIons run as | obs 

> IMultlole terminals per |ob 
lOn-llne llbrar'y maintenance 

l 1 Route Input messages 
I ISame processing tor all modes 
i IProuide clock or Interval timer 
lAssoclate queues with tasks 
I SOL statement to send messages 
' 'Perform I/O via standard Interfaces 
(Request resources on transaction basis 
ISuDmlt (obs to logical hosts 
(Route files between logical hosts 

IConcurrent database access In HMF 
ISame processing for all modes 
ILock/Unlock record-types and records 
I Transaction ownership of locks 
lUnlock after timeout period 
ICooy data to back-up copies 
ILock databases during Culet-Polnt 
IConcurrent database recovery 
•Database Administrator Interface 
ITreat locked updates as temporary 
I Update "all or none" on END_PA RCEL 
IWrite alter-images for recovery • 

'Undo temporary updates on ROLLBACK 
'Undo temporary updates on Unlock 
lEvaluata Test Node parameters 


.1 Yes 
I Yes 
I Yes 
I Yes 
1 Yes 


I No 
I Yes 
I Yes 


•I Yes 
I No 
I Yes 
I Yes 

I No. 

I Y e s 


1. No 
I, Yes 
I' No 
I Yea 

I No 
I... Yes 
I Yes 
I' . No 
INo' 
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116 lSupport test databases 

117 ILast Oulet-Polnt restorable 

118 (Recovery State/Node requests 

119 lOoerational State after recovery 

120 (Operational State/Mode requests 

121 (Record level security 

122 (Interfaces for the foI Iowlng roquestst 
I I - Lock/Unlock record-types 1 records 

I I - 0UIET_P0INT 

I I - <3EGIN_PARCEL 

I I - ROLLBACK 

I I - ENO_PARCEL 

I I - Restore database 

123 IAAM files recovery 

II 

Nat.Prod. 1 1 (Selectable mainframe connect In HMF 
I 2 (Permit busy terminal Input 
' 3 'Send messages re terminal connection 
I 9 ISame processing for at! modes 
' 5 I Transmit messages and files 
I 6 (Transform logical to physical devices 
7 1 h cccot single and broadcast r*ecsu**>t 
I 8 iIdentify unsolicited destinations 
I 9 Maintain unsolicited message queues 
110 (Alert on unsolicited output 

III lAlert at terminal login 

112 I Send unsolicited message to output 

113 (Discard messages after timeout 
Ilk I Enqueue multiple pages output 

115 lAlert wnen multiple pages 

116 I Process page selection reouests 

117 IDisnlay paqe number optionally 

118 ILIre count and Daqe delimiter 

119 I H i gh I 1 gh t ed fields -l cursor control 

120 ILoc a I-mode terminal suooorf 

121 I Vane cassette identification 

122 (Cassette I/O via standard protocols 

123 IAuto-baud and auto-tyoe 
I?k lAUto-dlal up support 

125 lldle terminal logout 

126 IBSC and SDLC protocols 

127 I Implicit terminal login 

128 IReroute terminal connections 

Comp.Prod.! 1 ICommon Interfaces tor all modes 

I 2 (Interfaces the followlrg requests! 

I I - Change task priority 
I I - New chain (NEWCHN) 

I I - Add chain (AOOCHNJ 

I I - New transaction (NEHTKN1 


No I 
Yes I 
No I 
No I 
NO I 
Ho I 
I 

No I 
No I 
No I 
No I 
No I 
No t 
No ! 

I 

No I 
Yes I 
Yes I 
Yes I 
Yes I 
Yes 1 
Yes I 
No I 
' No ! 

No I 
Mo 1 
No I 
No I 
Yes ! 
Yes ! 

No I 
No t 
Yes I 
No I 
▼ es I 
No I 
No I 
No I 
Yes I 
Yes 1 
No I 
No I I 

No I | 

! 

Yes I 
I 

No I 
No I 
No I 
No I 
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4.0 NOS/100 COMPONENT REQUIREMENT 


I I - End task (ENOTSKJ 
< I - Terminate active transactIons 
I I - _ Id I e/P.est art application 
I I - Eormatted-screen I/O 

• I - Sand messages and files • 

I I ■ File I/O ' 

I I - Record I/O' 

I 3 (Provide format Services utility 
I 4 IMap formatted-scraen data 
1 5 I Mai n't a I n Image definition 
I 6 (Validate l Justify formatted data 

I 7 ISend error indications to consoles 
(Communication block visibility 
IProvioe Message Control System fMCSI 
I 

I No transaction-only requirements 
ITask list oer transaction 
IProcass task list roquests 
tint t late next task 
I Prepare communication blocks 
l D ass communlca11 on blocks 
Maintain CO storage areas 
ISaye CB at transaction end and recover 
‘Establish .initial task list 
^Initiate ETftSK on fatal errorp 
Iferminate actlvo transactions 
(Idle and restart applications 
(Initialize application files 
IPelease Icons at transaction termlnati 
Module tables utilities 
(Validate transaction types 
(Construct task chains 
lEntble 3r,d disable selected groups 
I 

IResuhmlt transactions In Recovery Mode 
(Signal 09 Admin. after recovery 
(Periodically Status recovery 
(Restart application after recovery 
tissue cassette I/O reauests 
(Submit cassette transactions 
(Provide basic'Initla I-Task (ITASKt 
IProvlde basic frroi— Task (ETASKI 
IProvlde application admin. Interface 

110 IProvlde transactions rerun -ut 1.1 1 tv 

111 (Provide resource report generator 
11.2 IProvlde cassette submit utility 
113 IProvlde message parsing utility 

II 

User-Apol. I 1 Maintain terminal busy status - 

I 2 IPreoaro and se'nd status resoohse 
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I 8 
I 9 
i 

Tran.Exoc.I 1 
2 

3 

4 

5 
fi 
7 

I 8 
I 9 
110 
111 
112 
113 
11 *. 

115 

116 
11 / 

✓118 

I 

Soec.Proq.t 1 
I 2 
I 
I 
I 
I 
I 
I 
I 


* ’ ■ 


No 

1 

No 

. 1 

No 

1 

No 

1 

No 

1 

Yes 

1 

Y <2 S. 

1 

No 

I 

No 

1 

No 

’.. 1 

No 

: .1 

No 

1 

No 

1 

Yes 

1 


1 

Yes 

. t 

. No 

1 

No 

t 

No 

■4 1 

No 

' -1 

No 

• 1 

No 

V .1 

No 

1 

No 

; 1 

No 

>1 

No 

: 1 

No 

i 

No 

on 1 

No 

1 

No 

. 1 

No 

1 

No 

.1 

No 

: 1 

No 

1 

No 

1 

No 

:• i 

No 

t 

No 

■ i 

No 

ui 

No 

•: i 

No 

i 

No 

:• i 

No 

,, i 

No 

i 

No 

i 

No 

.1 

No 

■■i 

No 
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4.0 NOS/180 COMPONENT REQUIREMENT 



1 3 

1 Perlodlcal1y request Quiet-Point 

1 

No 



1 4 

lldte application before Oulet-Polnt 

1 

No 



1 5 

(Periodically status Quiet-Point 

1 

No 



1 6 

IPestgrt aoollcation after Quiet-Point 

1 

No 



1 7 

IProcess OHS-ifiO messages 

1 

No 



1 8 

tissue DMS-180 recovery reouests 

1 

No 



1 9 

IProvlde Test Mode selection logic 

1 

No 



110 

(Set Test Mode parameters 

1 

No 



111 

IReroute Test Mode I/O 

1 

No 



112 

ILog transactions for recovery 

1 

No 



113 

lldle aoDlication for recovery 

f 

No 



114 

1 Initiate rerun orocess 

1 

No 



115 

1 Reroute Recovery Mode I/O 

1 

No 



116 

•Initiate Cassette Submit utility 


No 



11/ 

ISend broadcast and queue messages 

! 

Yes 



118 

IProvlde Joos to Initiate applications 

1 

1 

1 

-«* 

Yes 

- <7 
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